Выполнение лабораторной работы
Выполнение лабораторной работы
Для начала выполнения второй лабораторной работы запустить виртуальную машину server. На виртуальной машине server вхожу под созданным предыдущей работе пользователем, antoychubekova и открываю терминал и перехожу в режим суперпользователя
![Переход в режим суперпользователя]()
## Выполнение лабораторной работы
Устанавливаю bind и bind-utils.
Выполнение лабораторной работы
В качестве упражнения с помощью утилиты dig делаю запрос, к DNS-адресу www.yandex.ru.
В первой строке указывается версия утилиты DiG 9.18.33 и сам домен, к которому выполняется запрос. Далее сообщается, что ответ получен, в заголовке видно, что это был обычный запрос (QUERY) со статусом NOERROR (ошибок нет), и указан идентификатор запроса. Флаги показывают, что это ответ (qr), была запрошена рекурсия (rd), и сервер её поддерживает (ra). Также указано, что в ответе одна секция запроса, три записи-ответа и одна дополнительная.
В блоке OPT PSEUDOSECTION видно, что используется расширение EDNS(0) версии 0, без дополнительных флагов, а максимальный размер UDP-пакета — 1232 байта. В секции QUESTION повторяется сам запрос: домен www.yandex.ru и тип записи A (IPv4-адрес).
Выполнение лабораторной работы
В ANSWER SECTION приходят три результата: www.yandex.ru сопоставлен с IP-адресами 77.88.55.88, 77.88.44.55 и 5.255.255.77, каждая запись имеет TTL 600 секунд (10 минут), то есть столько времени она может храниться в кэше.
В дополнительной информации указывается, что запрос занял 329 мс, ответ пришёл от DNS-сервера 213.186.33.99 (порт 53, UDP). Также зафиксировано точное время выполнения запроса — 11 сентября 2025 года, 11:10:30 (UTC). Размер полученного сообщения составил 90 байт.
Выполнение лабораторной работы
![]()
Утилита dig
Выполнение лабораторной работы
Открываю файл /etc/resolv.conf.
Файл /etc/resolv.conf задаёт настройки DNS для системы: в нём указываются адреса DNS-серверов (nameserver), к которым компьютер обращается для преобразования доменных имён в IP-адреса (по порядку, пока один не ответит), и домен поиска (search antoychubekova.net), который автоматически добавляется к коротким именам хостов.
Выполнение лабораторной работы
![]()
Файл /etc/resolv.conf
Выполнение лабораторной работы
Открываю файл named.conf.
Этот файл named.conf — конфигурация DNS-сервера BIND. В нём указано, что сервер слушает запросы только на локальных адресах 127.0.0.1 (IPv4) и ::1 (IPv6), то есть работает как локальный кэширующий резолвер. Заданы служебные файлы: директория для работы /var/named, файлы для дампов кэша, статистики, памяти и ключей, а также файл для рекурсивных запросов. В настройке allow-query { localhost; }; указано, что отвечать на DNS-запросы сервер будет только самому себе (локальной машине). Включена опция recursion yes;, что делает сервер рекурсивным кэширующим DNS, пригодным для локального разрешения имён, и включена проверка DNSSEC (dnssec-validation yes;) для дополнительной безопасности.
Выполнение лабораторной работы
![]()
Файл named.conf
Выполнение лабораторной работы
Открываю файл named.ca.
Этот файл named.ca содержит список корневых DNS-серверов Интернета (root servers), необходимых для инициализации работы DNS-сервера BIND: он задаёт, какие серверы считаются корневыми и по каким IP-адресам (IPv4 и IPv6) их можно достичь. Благодаря этому DNS-сервер знает, с чего начинать поиск доменов в глобальной сети.
Выполнение лабораторной работы
![]()
Файл named.ca
Выполнение лабораторной работы
Открываю файл named.localhost.
Этот файл named.localhost описывает зону DNS для домена localhost. В нём задаётся основная запись SOA (Start of Authority) с параметрами обновления зоны и фиктивным адресом администратора (rname.invalid.), а также указываются записи: NS (сервер имён — сам localhost), A (IPv4-адрес 127.0.0.1) и AAAA (IPv6-адрес ::1). Таким образом, он нужен для того, чтобы DNS-сервер BIND правильно обрабатывал запросы к имени localhost и всегда резолвил его в локальный адрес.
Выполнение лабораторной работы
![]()
Файл named.localhost
Выполнение лабораторной работы
Открываю файл named.loopback.
Этот файл named.loopback описывает обратную (reverse) DNS-зону для интерфейса loopback. В нём задаётся запись SOA (Start of Authority) с параметрами зоны, указывается, что сервер имён (NS) — это сам localhost, и определяются адреса: A (127.0.0.1 для IPv4) и AAAA (::1 для IPv6). Дополнительно здесь есть запись PTR, которая обеспечивает обратное преобразование IP-адреса 127.0.0.1 в имя localhost. То есть этот файл нужен, чтобы при обратных DNS-запросах (по IP) адрес loopback корректно резолвился в localhost.
Выполнение лабораторной работы
![]()
Файл named.loopback
Выполнение лабораторной работы
Запускаю DNS-сервер. Включаю запуск днс-сервера в авозапуск при загрузки системы.
![]()
Запуск DNS-сервера
Выполнение лабораторной работы
Ввожу в команду dig @127.0.0.1 www.yandex.ru. dig www.yandex.ru показывает работу с внешним DNS (сразу из resolv.conf), а dig @127.0.0.1 www.yandex.ru — проверку твоего локального BIND как резолвера. В твоём случае оба возвращают одинаковые IP-адреса Яндекса, но второй запрос идёт через твой сервер, а не напрямую к провайдерскому DNS.
Выполнение лабораторной работы
![]()
Вывод ig @127.0.0.1 www.yandex.ru.
Выполнение лабораторной работы
Делаю DNS-сервер сервером по умолчанию для хоста server и внутренней виртуальной сети. Для этого изменяю настройки сетевого соединения eth0 в NetworkManager, переключив его на работу с внутренней сетью и указав для него в качестве DNS-сервера по умолчанию адрес 127.0.0.1.
Выполнение лабораторной работы
![]()
DNS-сервер сервером по умолчанию для хоста server и внутренней виртуальной сети
Выполнение лабораторной работы
Делаю тоже самое для соединения System eth0. Оно у нас не активно.
![]()
DNS-сервер сервером по умолчанию для хоста server и внутренней виртуальной сети
Выполнение лабораторной работы
Перезапускаю NetworkManager. Проверяю наличие изменений в файле /etc/resolv.conf.
![]()
Перезапуск NetworkManager
Выполнение лабораторной работы
Настраиваю направление DNS-запросов от всех узлов внутренней сети, включая запросы от узла server. Для этого вношу изменения в файл /etc/named.conf, заменив строку:
listen-on port 53 { 127.0.0.1; };
на
listen-on port 53 { 127.0.0.1; any; };
и строку
allow-query { localhost; };
на
allow-query { localhost; 192.168.0.0/16; };
Выполнение лабораторной работы
![]()
Настройка направление DNS-запросов
Выполнение лабораторной работы
Вношу изменение в настройки межсетевого экрана узла server, разрешив работу с DNS.
![]()
Внесение изменений
Выполнение лабораторной работы
Введя команду lsof | grep UDP мы убедились что DNS-запросы идут через узел server, который прослушивает порт 53.
![]()
Проверка DNS-запросов
Выполнение лабораторной работы
В случае возникновения в сети ситуаций, когда DNS-запросы от сервера фильтруются сетевым оборудованием, следует добавить перенаправление DNS-запросов на конкретный вышестоящий DNS-сервер. Для этого в конфигурационном файле named.conf в секции option следует добавить:
forwarders { список DNS-серверов };
forward first;
Возможно вышестоящий DNS-сервер может не поддерживать технологию dnssec, из за этого в конфигурационном файлике указываю следующие настройки:
dnssec-enable no;
dnssec-validation no;
Выполнение лабораторной работы
![]()
Перенаправление DNS-запросов
Выполнение лабораторной работы
Копирую шаблон описания DNS-зон named.rfc1912.zone из каталога /etc в каталог /etc/named и переименовываю его в antoyxhubekova.net.
![]()
Редактирование файлов
Выполнение лабораторной работы
Включаю файл описания зоны /etc/named/antoychubekova.net в конфигурационном файле DNS /etc/named.conf, добавив в нём в конце строку:
include “/etc/named/antoychubekova.net”;
![]()
Включение файла описания зоны /etc/named/antoychubekova.net
Выполнение лабораторной работы
Открываю файл /etc/named/antoychubekova.net на редактирование и записываю:
zone “antoychubekova.net” IN {
type master;
file “master/fz/antoychubekova.net”;
allow-update { none; };
};
zone “1.168.192.in-addr.arpa” IN {
type master;
file “master/rz/192.168.1”;
allow-update { none; };
};
Выполнение лабораторной работы
![]()
Редактирование /etc/named/antoychubekova.net
Выполнение лабораторной работы
В каталоге /var/named создаю подкаталоги master/fz и master/rz, в которых будут располагаться файлы прямой и обратной зоны соответственно.
![]()
Редактирование /var/named
Выполнение лабораторной работы
Копирую шаблон прямой DNS-зоны named.localhost из каталога /var/named в каталог /var/named/master/fz и переименовываю его в antoychubekova.net.
![]()
Копирование шаблон прямой DNS-зоны
Выполнение лабораторной работы
Изменяю файл /var/named/master/fz/antoychubekova.net, указав необходимые DNS-записи для прямой зоны. В этом файле DNS-имя сервера @ rname.invalid. заменыю на @ server.antoychubekova.net. ; формат серийного номера ГГГГММДДВВ (2025091100); адрес в A-записи заменяю с 127.0.0.1 на 192.168.1.1; в директиве $ORIGIN задаю текущее имя домена antoychubekova.net., а затем указываю имена и адреса серверов в этом домене в виде A-записей DNS.
Выполнение лабораторной работы
![]()
Редактирование /var/named/master/fz/antoychubekova.net
Выполнение лабораторной работы
Копирую шаблон обратной DNS-зоны named.loopback из каталога /var/named в каталог /var/named/master/rz и переминовываю его в 192.168.1
![]()
Копирование шаблон обратной DNS-зоны named.loopback
Выполнение лабораторной работы
Изменяю файл /var/named/master/rz/192.168.1, указав необходимые DNS-записи для обратной зоны. В этом файле DNS-имя сервера @ rname.invalid. заменяю на @ server.user.net. ; формат серийного номера ГГГГММДДВВ (2025091100); адрес в A-записи заменяю с 127.0.0.1 на 192.168.1.1; в директиве $ORIGIN задаю название обратной зоны в виде 1.168.192.in-addr.arpa., затем задаю PTR-записи.
![]()
Редактирование /var/named/master/rz/192.168.1
Выполнение лабораторной работы
Далее исправляю права доступа к файлам в каталогах /etc/named и /var/named, чтобы демон named мог с ними работать.
![]()
Изменение прав доступа к /etc/named и /var/named
Выполнение лабораторной работы
В системах с запущенным SELinux все процессы и файлы имеют специальные метки безопасности (так называемый «контекст безопасности»), используемые системой для принятия решений по доступу к этим процессам и файлам. После изменения доступа к конфигурационным файлам named корректно восстанавливаю их метки в SELinux.
![]()
Корректное восстановление меток в SELinux
Выполнение лабораторной работы
Для проверки состояния переключателей SELinux, относящихся к named, ввожу: getsebool -a | grep named.
![]()
Состояния переключателей SELinux
Выполнение лабораторной работы
Даю named разрешение на запись в файлы DNS-зоны.
![]()
Предоставление разрешения на запись в файлы DNS-зоны
Выполнение лабораторной работы
В дополнительном терминале запускаю в режиме реального времени расширенный лог системных сообщений, чтобы проверить корректность работы системы. Мы видим, что корректно отрабатывается.
![]()
Проверка корректности работы системы
Выполнение лабораторной работы
В первом терминале перезапускаю DNS-сервер. При помощи утилиты dig получаю описание DNS-зоны с сервера ns.antoychubekova.net. В выводе видно, что запрос успешно обработан (status: NOERROR) и возвращён авторитетный ответ (aa — authoritative answer) от вашего локального DNS-сервера на 127.0.0.1. В разделе ответа указано, что ns.antoychubekova.net имеет A-запись с адресом 192.168.1.1, TTL установлен на 86400 секунд (1 день). Время обработки запроса составило 2 мс, что подтверждает, что локальный сервер функционирует корректно и возвращает IP для указанного имени.
Выполнение лабораторной работы
![]()
Описание DNS-зоны с сервера ns.antoychubekova.net
Выполнение лабораторной работы
При помощи утилиты host проанализирую корректность работы DNS-сервера.
В выводе команды host -l antoychubekova.net видно, что указаны следующие записи: основной сервер имени antoychubekova.net и его IP 192.168.1.1, а также дополнительные записи ns.antoychubekova.net и server.antoychubekova.net, все с тем же IP 192.168.1.1. Это говорит о том, что локальный DNS-сервер правильно отвечает на запросы и возвращает все настроенные записи зоны.
Выполнение лабораторной работы
![]()
Корректность работы DNS-сервера
Выполнение лабораторной работы
Команда host a antoychubekova.net, которая по сути запрашивает все записи (ANY) для домена antoychubekova.net. В выводе видно, что сервер вернул статус NOERROR, что означает успешное выполнение запроса. В разделе ответа содержатся три записи: SOA (Start of Authority) с корректными параметрами зоны, NS-запись, указывающая на сам домен как сервер имён, и A запись с IP 192.168.1.1. Время ответа составило 8 мс, и ответ получен от локального сервера 127.0.0.1. Это говорит о том, что локальный DNS-сервер BIND работает корректно.
Выполнение лабораторной работы
![]()
Корректность работы DNS-сервера
Выполнение лабораторной работы
Команда host -t A antoychubekova.net возвращает, что antoychubekova.net имеет адрес 192.168.1.1. Значит все корректно отрабатывается.
![]()
Корректность работы DNS-сервера
Выполнение лабораторной работы
В ответе сервер возвращает две PTR-записи: ns.antoychubekova.net и server.antoychubekova.net. Технически это означает, что обратное разрешение работает — IP связан с доменными именами.
![]()
Корректность работы DNS-сервера
Выполнение лабораторной работы
На виртуальной машине server перехожу в каталог для внесения изменений в настройки внутреннего окружения /vagrant/provision/server/, и создаю в нём каталог dns, в который помещаю в соответствующие каталоги конфигурационные файлы DNS.
![]()
Редактирование конфигурационных файлов DNS
Выполнение лабораторной работы
В каталоге /vagrant/provision/server создаю исполняемый файл dns.sh.
![]()
Создание исполняемого файла dns.sh
Выполнение лабораторной работы
Открыв его на редактирование, пропишите в нём скрипт, по сути, повторяющий произведённые выше действия по установке и настройке DNS-сервера: подставляет в нужные каталоги подготовленные конфигурационные файлы; меняет соответствующим образом права доступа, метки безопасности SELinux и правила межсетевого экрана; настраивает сетевое соединение так, чтобы сервер выступал DNS-сервером по умолчанию для узлов внутренней виртуальной сети; запускает DNS-сервер.
Выполнение лабораторной работы
![]()
Редактирование исполняемого файла dns.sh
Выполнение лабораторной работы
Для отработки созданного скрипта во время загрузки виртуальной машины server в конфигурационном файле Vagrantfile добавляю в разделе конфигурации для сервера:
server.vm.provision “server dns”,
type: “shell”,
preserve_order: true,
path: “provision/server/dns.sh”
Выполнение лабораторной работы
![]()
Редактирование Vagrantfile
Выводы
В ходе выполнения лабораторной работы №2 я приобрела практические навыки по установке и конфигурированию DNS-сервера, усвоила принцип работы системы доменных имён.
Список литературы
- Barr D. Common DNS Operational and Configuration Errors: RFC / RFC Editor. —02/1996. — DOI: 10.17487/rfc1912.
- Security-Enhanced Linux. Linux с улучшенной безопасностью: руководство пользователя / M. McAllister, S. Radvan, D. Walsh, D. Grift, E. Paris, J. Morris. — URL: https://docs-old.fedoraproject.org/ru-RU/Fedora/13/html/Security-Enhanced_Linux/index.html (дата обр.13.09.2021).
- Systemd. — 2015. — URL: https:/ /wiki .archlinux .org /index .php /Systemd (visited on 09/13/2021).
- Костромин В. А. Утилита lsof — инструмент администратора. — URL: http : / / rus linux.net/kos.php?name=/papers/lsof/lsof.html (дата обр. 13.09.2021).
- Поттеринг Л. Systemd для администраторов: цикл статей. — 2010. — URL: http : wiki.opennet.ru/Systemd (дата обр. 13.09.2021).
## Выполнение лабораторной работы
